Add `bounds::FloatPrimitive`

Exhaustive float pattern match

Fix GCC

use span bugs

…sics

This create conflict if the timespec of a target has additional fields.
Use libc::timespec::default() instead

stabilizes `core::range::RangeFrom`
stabilizes `core::range::RangeFromIter`

add examples for `remainder` method on range iterators
`RangeFromIter::remainder` was not stabilized (see issue 154458)

…gross35

Update libc to v0.2.183

Follow-up of rust-lang#150484.
This PR updates libc to include the latest patches to make rtems target (and probably others) compile again.

…, r=tgross35

stabilize new RangeFrom type and iterator

```rust
// in core and std
pub mod range;

// in core::range

pub struct RangeFrom<Idx> {
    pub start: Idx,
}

impl<Idx: fmt::Debug> fmt::Debug for RangeFrom<Idx> { /* ... */ }

impl<Idx: PartialOrd<Idx>> RangeFrom<Idx> {
    pub const fn contains<U>(&self, item: &U) -> bool
    where
        Idx: [const] PartialOrd<U>,
        U: ?Sized + [const] PartialOrd<Idx>;
}

impl<Idx: Step> RangeFrom<Idx> {
    pub fn iter(&self) -> RangeFromIter<Idx>;
}

impl<T> const RangeBounds<T> for RangeFrom<T> { /* ... */ }
impl<T> const RangeBounds<T> for RangeFrom<&T> { /* ... */ }

impl<T> const From<RangeFrom<T>> for legacy::RangeFrom<T> { /* ... */ }
impl<T> const From<legacy::RangeFrom<T>> for RangeFrom<T> { /* ... */ }

pub struct RangeFromIter<A>(/* ... */);

// `RangeFromIter::remainder` left unstable

impl<A: Step> Iterator for RangeFromIter<A> {
    type Item = A;
    /* ... */
}

impl<A: Step> FusedIterator for RangeFromIter<A> { }
impl<A: Step> IntoIterator for RangeFrom<A> {
    type Item = A;
    type IntoIter = RangeFromIter<A>;
    /* ... */
}

unsafe impl<T> const SliceIndex<[T]> for range::RangeFrom<usize> {
    type Output = [T];
    /* ... */
}
unsafe impl const SliceIndex<str> for range::RangeFrom<usize> {
    type Output = str;
    /* ... */
}

impl ops::Index<range::RangeFrom<usize>> for CStr {
    type Output = CStr;
    /* ... */
}
```

Tracking issue: rust-lang#125687

…tgross35,RalfJung

Merge `fabsf16/32/64/128` into `fabs::<F>`

Following [a small conversation on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Float.20intrinsics/with/521501401) (and because I'd be interested in starting to contribute on Rust), I thought I'd give a try at merging the float intrinsics :)

This PR just merges `fabsf16`, `fabsf32`, `fabsf64`, `fabsf128`, as it felt like an easy first target.

Notes:
- I'm opening the PR for one intrinsic as it's probably easier if the shift is done one intrinsic at a time, but let me know if you'd rather I do several at a time to reduce the number of PRs.
- Currently this PR increases LOCs, despite being an attempt at simplifying the intrinsics/compilers. I believe this increase is a one time thing as I had to define new functions and move some things around, and hopefully future PRs/commits will reduce overall LoCs
- `fabsf32` and `fabsf64` are `#[rustc_intrinsic_const_stable_indirect]`, while `fabsf16` and `fabsf128` aren't; because `f32`/`f64` expect the function to be const, the generic version must be made indirectly stable too. We'd need to check with T-lang this change is ok; the only other intrinsics where there is such a mismatch is `minnum`, `maxnum` and `copysign`.
- I haven't touched libm because I'm not familiar with how it works; any guidance would be welcome!

…alebzulawski,antoyo

simd_fmin/fmax: make semantics and name consistent with scalar intrinsics

This is the SIMD version of rust-lang#153343: change the documented semantics of the SIMD float min/max intrinsics to that of the scalar intrinsics, and also make the name consistent. The overall semantic change this amounts to is that we restrict the non-determinism: the old semantics effectively mean "when one input is an SNaN, the result non-deterministically is a NaN or the other input"; the new semantics say that in this case the other input must be returned. For all other cases, old and new semantics are equivalent. This means all users of these intrinsics that were correct with the old semantics are still correct: the overall set of possible behaviors has become smaller, no new possible behaviors are being added.

In terms of providers of this API:
- Miri, GCC, and cranelift already implement the new semantics, so no changes are needed.
- LLVM is adjusted to use `minimumnum nsz` instead of `minnum`, thus giving us the new semantics.

In terms of consumers of this API:
- Portable SIMD almost certainly wants to match the scalar behavior, so this is strictly a bugfix here.
- Stdarch mostly stopped using the intrinsic, except on nvptx, where arguably the new semantics are closer to what we actually want than the old semantics (rust-lang/stdarch#2056).

Q: Should there be an `f` in the intrinsic name to indicate that it is for floats? E.g., `simd_fminimum_number_nsz`?

Also see rust-lang#153395.

…ark-Simulacrum

triagebot: add reminder for bumping CI LLVM stamp

I'm not sure what else can be done automatically to help us not forget this, but at least this gives a chance for the PR author/reviewer to be reminded (e.g. myself).

…alueFormat-dist-x86_64, r=marcoieni

Fix LegacyKeyValueFormat report from docker build: dist-x86_64

Part of rust-lang#152305

r? @marcoieni

…s, r=Mark-Simulacrum

`trim_prefix` for paths

under rust-lang#142312?

its a useful method.

…triddle

Fix ice in rustdoc of private reexport

Fixes rust-lang#154383

The root cause is rustdoc could still try to resolve links for source docs that resolver did not cache in `ResolveDocLinks::Exported` mode. The test case will not crash with `--document-private-items` option, which will use `ResolveDocLinks::All`.

The fix makes rustdoc skip link resolution based on the source `DefId` of each doc fragment, so its behavior stays aligned with resolver's logic here: https://github.com/chenyukang/rust/blob/dc5cb1719eed6ac9275fe93d914d32141606b2ac/compiler/rustc_resolve/src/late.rs#L685

Notify stdarch maintainers on changes in std_detect

cc @Amanieu @folkertdev @Kobzol

It would be nice to be notified when std_detect changes, as it is spiritually a part of stdarch.

Also assign @rust-lang/libs to std_detect